Video

Beschrijving

Een use case bestaat actoren (gebruikersrollen, aangeduid met een draadpoppetje) en use cases (scenario’s, aangeduid met een ellips) die de actor kan uitvoeren.

Een use case beschrijft alleen de interactie, niet de interne werking van het systeem. Use cases kunnen goed met eindgebruikers besproken worden, omdat ze aansluiten bij hun ervaringsswereld.

De naam van een use case bestaat over het algemeen uit een zelfstandig naamwoord en een werkwoord.

Use Cases zijn daardoor geschikt om MVC applicaties te modelleren (ook Razor Pages die op ASP.NET MVC zijn gebouwd). Het zelfstandig naamwoord komt overeen met de controllernaam en het werkwoord met de naam van een functie uit de controller klasse. Dit stemt overeen met 'propere" url's waarbij de gebruiker de volgende url's ingeeft:

Gebruik

Mijn overtuiging over het belang van use cases als vertrekpunt voor het schrijven van applicaties dateert al van heel lang. Mijn benadering van use cases zijn gebaseerd op Jacobson's Objectory-proces, gedefinieerd in Object-Oriented Software Engineering: A Use Case Driven Approach (Addison-Wesley, 1992). Een sleutelpassage legt uit wat er bedoeld wordt met use case driven:

Als we het systeemgedrag willen veranderen, hermodelleren we de juiste actor en use case. De hele systeemarchitectuur wordt bepaald door wat de gebruikers met het systeem willen doen. Aangezien we dit kunnen opvolgen doorheen alle, zullen we het systeem kunnen aanpassen aan nieuwe vereisten. We vragen de gebruikers wat ze willen veranderen (welke use case) en kijken direct waar deze wijzigingen in de andere modellen moeten worden aangebracht.

Een meer recent boek hierover:

Don Rosenberg, Matt Stephens, Use Case Driven Object Modeling with UML, Theory and Practice, Uitgeverij: Apress, 21/01/2013

Voorbeeld

Ik ben op een bepaald moment use cases beginnen gebruiken om de CRUD (create, read, update en delete) operaties voor entiteiten (tabellen) te modelleren. Dit heeft me geholpen om een overzicht te krijgen van alle stappen die gezet moeten worden vanuit het MVC (Model, View, Contrller) perspectief.

Sommige collega's vonden totaal overbodig voor deze zogenaamde eenvoudige operaties. Laten we het toch meer eens uitproberen en kijken als het iets oplevert. Als voorbeeld nemen we de entiteit/tabel Person. We willen een use diagram uitwerken waarbij we willen uittekenen wat een gebruiker moet kunnen doen voor het bewerken van persoonsgegevens in de Person entiteit/tabel.

We beginnen met een use case diagram. We geven hier het voorbeeld van de tabel/entiteit Person:

Use case elementen

1. Actor
   
   Een actor stelt de entiteiten voor die bepaalde rollen in een bepaald systeem vervullen. De verschillende rollen die de actor kan spelen, zijn de use cases van de gebruikers in een bepaald systeem. Een actor in een use case-diagram heeft interactie met een use case.Een actor wordt weergegeven door een stokfiguur in een use case-diagram dat "buiten" de systeemgrens wordt afgebeeld, zoals weergegeven in de afbeelding.
2. Use case
   
   De use case wordt voorgesteld door een ovaal met daarin een naam die bepaalde functionaliteit omschrijft. Een goede use case is er een die het doel van de use case het best omschrijft. Bijvoorbeeld: “bekijk boekenlijst”, “wijzig besteloverzicht” of “bekijk boek informatie”.
   Meestal bestaat een use case uit een zelfstandig naamwoord en een werkwoord.
3. Verwantschappen (relationships)
   
   Illustreer verwantschappen tussen een actor en een use case met een simpele lijn. Gebruik voor relaties tussen use-cases pijlen met het label "include" of "extends". Een "include"-verwantschap geeft aan dat de ene use-case nodig is voor de andere om een taak uit te voeren. Een "extend"-verwantschap geeft alternatieve opties aan onder een bepaalde use case. Of nog anders gezegd, wanneer je pijlen tekent tussen use cases dan kanje aangeven of de twee use cases elkaar nodig hebben (noteer “uses” of “include”) of een optionele aanvulling op elkaar zijn (“extends”).
4. Systeem
   
   Het systeem (grens, boundery) is in ons geval de webpagina's waarmee de tabel Person wordt beheerd. Binnen het kader van het systeem noteer je de specifieke use cases, de actors staan daar altijd buiten. Een systeem kan ook een versienummer hebben. Zo kun je bijvoorbeeld aangeven in welke versie van je website een use case wordt geïntroduceerd.
   In het voorbeeld hierboven hebben we de use cases getekend voor het beheersysteem. We hebben geen use cases getekend voor andere systemen, bijvoorbeeld een registratie systeem. In de opdracht zijn er twee systemen.
   Je kan systemen ook laten overlappen of nesten. Een mooi voorbeeld is het gebruik van systemen voor het weergeven van verschillende releases:

   

Use case beschrijvingen

We beschrijven alleen de use cases voor Peroon in detail. Meestal worden wireframes gelijktijdig gemaakt. Beide tools ondersteunen elkaar. Voor de wireframes kan je terecht op: Fric-frac Wireframes Person.

Person ReadingAll

Deze use case is een uitbreiding van andere use cases. Vandaar dat we die eerst beschrijven.

Person Index

Person InsertingOne

Een eerste poging tot het beschrijven van Person InsertingOne.

De beheerder moet de mogelijkheid hebben om een nieuwe persoon toe te voegen. Na het intypen van de nieuwe gegevens moet het programma de nieuwe persoon in de tabel Person inserten. Zie hievoor de use case hieronder.

Person InsertOne

En nu een eerste poging tot het beschrijven van de use case Person InsertOne:

Person UpdatingOne

Een eerste poging tot het beschrijven van Person Updating.

De beheerder moet de mogelijkheid hebben om de gegevens van een bestaande persoon te wijzigen. Na het intypen van de nieuwe gegevens moet het programma de gewijzigde persoon in de tabel Person updaten. Zie hievoor de use case hieronder.

Person UpdateOne

En nu een eerste poging tot het beschrijven van de use case Person UpdateOne:

Person DeleteOne

En nu een eerste poging tot het beschrijven van de use case Person DeleteOne:

Opdracht

Tweedehandsboeken website

1. Maak op basis van de functionele vereisten een use case diagram:
   1. bepaal welke actoren er deel nemen
   2. noteer de acties die elk van deze actor moet kunnen doen
2. Voor zover het mogelijk is, begin de use case beschrijvingen te maken.
3. Functionele vereisten
   We maken een onderscheid tussen de handelaar (beheer) en koper (bezoeker). We hebben dus twee systemen:
   1. beheer
      1. een lijst van alle boeken:
         1. zoeken op titel, auteur, categorie en EAN
         2. een boek selecteren om de gegevens ervan te kunnen lezen
         3. deze lijst moet op alle beheerpagina's te zien zijn
      2. index pagina met lijst van alle boeken en de mogelijkheid een boek toe te voegen
      3. Reading One pagina waarop de gegevens van 1 boek te zien zijn. Met de volgende mogelijkheden:
         1. het getoonde boek deleten
         2. het getoonde boek updaten
         3. een nieuw boek toevoegen
      4. Inserting One pagina waarmee een nieuw boek kan worden toegevoegd
      5. Updating One pagina waarmee de gegevens van een geselecteerd boek kunnen worden geüpdated
   2. bezoeker
      1. toon de 10 laatste boeken die zijn ingebracht
      2. boeken kunnen opzoeken op auteursnaam, titel, EAN en categorie
      3. boek in winkelwagentje zetten
      4. boeken die in winkelwagentje staan bestellen via een bestelformulier (geen mogelijkheid om online te betalen)
      5. inhoud van winkelwagentje beheren:
         1. bekijken
         2. item deleten
         3. bestellen
         4. bewaren voor een volgende keer